home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Monster Media 1996 #15
/
Monster Media Number 15 (Monster Media)(July 1996).ISO
/
bbs_game
/
oxv300.zip
/
SYSOP.DOC
< prev
next >
Wrap
Text File
|
1996-05-17
|
51KB
|
1,052 lines
IRON OX Version 3.00
(C)opyright 1993-1996, Joel W. Downer
Support BBS: Fido 1:202/704, 619-462-8406/462-7146
Inquiries: joel@dreamcty.cts.com
CONTENTS
This documentation file includes the following sections:
SUMMARY What this door is and why you want it!
EVALUATION VERSION Shareware notice; evaluation terms
COMPATIBILITY/REQUIREMENTS What you need to run this program
INSTALLING THE GAME How to get the game running
TRYING OUT THE GAME How to take a look at this door
IRON OX AND YOUR BBS Getting the game working from your BBS
COMMAND-LINE ARGUMENTS List of options accepted by the program
MULTINODE SETUP Special issues for multinode sysops
COMMON PROBLEMS Please read *before* calling me at 3 AM <g>
CONFIGURING IRON OX Customizing your IRONOX.CFG file
EXTERNAL PROTOCOLS Setting up external protocols with Iron Ox
MAINTAINING IRON OX To keep the door running over time...
CUSTOMIZING Touching up the program to your taste
ERRORLEVELS Information for tech geek sysops <g>
LICENSE/REG. INFORMATION How to register your copy of Iron Ox!
ADDITIONAL LICENSE INFO Info on distributing/licensing this door
FUTURE PLANS Some information about what lies ahead
SUPPORT Where to get more help!
DISTRIBUTION SITES Where to find the latest version.
OTHER SOFTWARE BY JOEL DOWNER If you like Iron Ox....
DISCLAIMER Boilerplate courtesy of legal dept. <g>
ACKNOWLEDGEMENTS The names of a few heroes/heroines
SUMMARY
Iron Ox is an interactive strategy game intended to be run as a BBS
external program (door). The players have been sent against their will
to an untamed alien world: they start with their bare hands, a few
automated "iron oxen" to help them build things, and a small pack of
cybernetically modified dogs ("cybermutts") to protect them. Will your
callers work together to master the world and build a flourishing
civilization, with roads and freeways and a powerful economy? Or will
they destroy each other and the planet beneath their feet as they
struggle for dominance? And what about neighboring worlds? Rumors brew
that the other colonies are building armies ... if war erupts, will your
BBS's callers be ready?
Iron Ox is a rich game, with exciting features like:
* RIP graphics support, with beautiful art and (optional) local RIP!
* five-minute setup with a one-line batch file on most systems,
* detection and timeslicing for DESQview, Windows, and OS/2,
* full multinode support, with real-time chat, messaging, and combat!
* support for a wide variety of door drop files (including DOOR.SYS,
DORINFO?.DEF, EXITINFO.BBS, CHAIN.TXT, CALLINFO.BBS, and SFDOORS.DAT),
* support for direct serial communications or FOSSIL,
* a native, 32-bit OS/2 version available,
* purchasable drones that work the land and fight in real time, and
* full InterBBS league support, including IBBS attacks and ops!
EVALUATION VERSION
Iron Ox is distributed in an evaluation version, intended for you to try
out for thirty days. The evaluation version of Iron Ox is a complete
and (I hope) enjoyable game. If you like Iron Ox and wish to continue
using it after thirty days, please see "LICENSING/REGISTRATION
INFORMATION," below, for details on how to register. A registration key
for Iron Ox will enable additional features that will make the game even
more exciting for your users.
Thanks for evaluating Iron Ox!
COMPATIBILITY/REQUIREMENTS
The DOS version of Iron Ox requires about 400k of memory to run in text
mode, and about 450k to run with local graphics. (Having more memory,
and some EMS memory available, will make it run faster.)
Iron Ox requires a minimum 286 or better CPU, and a 386 or better is
recommended for best performance. On slower systems, you may wish to
adjust "Drone Cycles" in OxConfig (slowing down the computer-controlled
characters) to reduce the delay between moves. On a fast 486 or Pentium
system, you may actually want to *increase* the speed of the drones for
more exciting real-time action. :-)
Running Iron Ox in graphics mode (with the /LRIP parameter) requires a
monitor with EGA or better graphics support. The game will work fine on
any sort of monitor running without the /LRIP parameter. Local graphics
will work under DESQview and other DOS multitaskers, but using graphics
on multitasking multinode systems is not recommended. In particular,
having two or more sessions on one machine trying to do local graphics
at the same time is a bad idea.
Iron Ox (for DOS or OS/2) requires a minimum of 1.5 megabytes of disk
space. When running with local graphics, it may consume another
200-350k of space for temporary icon storage. A hard disk is required.
The DOS version runs under (and gives up timeslices to) DESQview,
Windows, and OS/2. (If you're running OS/2, though, you'll probably
want Iron Ox for OS/2.)
The DOS version includes internal comm routines, with support for
non-standard IRQ's and for rates of up to 115Kbps, as well as support
for a FOSSIL driver. Support for some specialized requirements
(DigiBoards, shared IRQ's) is provided in the DOS version through the
FOSSIL standard. Recent versions of several popular FOSSIL drivers are
available through the support BBS. If you're running the OS/2 version
of the door, don't worry about any of these issues: your device driver
will take care of them.
Iron Ox requires that the remote user (your caller) have ANSI, AVATAR,
or RIP graphics, but does not require special drivers on the sysop end.
INSTALLING THE GAME
This section describes how to set up Iron Ox in single-BBS mode. If
you're setting up Iron Ox for interBBS league play, see INTERBBS.DOC for
instructions.
Here's what it takes to install Iron Ox:
1. Unpack the Iron Ox archive into its own directory (all of the
examples in this .DOC file assume you've used C:\DOOR\IRONOX, but any
directory will do).
2. Run INSTALL.BAT (INSTALL.CMD under OS/2) and follow the instructions
that appear on the screen. (In case you want to recreate these steps
manually, INSTALL.BAT/INSTALL.CMD runs OxConfig to create your
configuration file and your batch file and then runs IRONOX /RESET to
create a new Iron Ox game.)
3. Be sure to say "Yes" to the questions about saving your configuration
file and creating a new game. Otherwise, though, you can mostly just
accept all the defaults at this point. (You can always go into
OxConfig later and fine-tune your configuration.) If you have an
external protocol like DSZ (DOS) or CEXYZ/2 (OS/2) installed, be sure
to visit General Settings|General Config in OxConfig and set the
pathname for your external protocol so Ox can automatically send RIP
icon files to RIP terminal users.
At the end, the installation process displays some instructions on the
screen about adding Iron Ox to your BBS. You can follow those
instructions now, or wait until you've "previewed" Ox as described in
the next section.
TRYING OUT THE GAME
Iron Ox is at its best with multiple players. However, if you like to
get acquainted with a game before offering it to your callers, you can
easily play a few turns on your own to see what it feels like. After
you've set up the game as described under "INSTALLING THE GAME," above,
just access the game locally by typing:
C:\IRONOX>IRONOX -LOCAL
If you're running the DOS version of Iron Ox and you have an EGA monitor
or better, you can have graphics by using this command-line instead:
C:\IRONOX>IRONOX -LOCAL -LRIP
When you're done playing a turn, you can advance to a new turn using:
C:\IRONOX>IRONOX -MAINT
IRON OX AND YOUR BBS
If you've gotten this far, I assume that you liked what you saw when you
followed the "TRYING OUT THE GAME" instructions. Great! Now, let's get
Iron Ox working as a door on your BBS.
This section includes three subsections: getting Ox for DOS to work
with a DOS BBS, getting the OS/2 version to work with an OS/2 BBS, and
using the OS/2 version with a DOS BBS running in the OS/2 DOS box.
(Whew! That was a mouthful. <g>) Make sure you understand which
situation applies to you and that you have the right version for your
operating system, because the differences are important.
Iron Ox for DOS and a DOS BBS:
Here are the key steps to installing Iron Ox for DOS:
1. Create a batch file your BBS can use to start the door. The easiest
way to do this is to use the "Make Batch File" option in OxConfig.
If you need to build a batch file manually from scratch (say, because
the one OxConfig creates isn't working for you), start with this:
C:\DOOR\IRONOX\IRONOX.EXE
If you want local RIP graphics and you have an EGA monitor or better,
it'll look more like this:
C:\DOOR\IRONOX\IRONOX.EXE -LRIP
If you are running a multinode DORINFOx.DEF BBS, if your BBS doesn't
launch door execution from the same directory where it creates
dropfiles (Maximus often doesn't), or if you're using a non-standard
comm port under DOS and aren't running a FOSSIL driver, you'll need
to use additional command-line parameters. See the file SAMPLE.BAT
for examples, or the section below on "COMMAND-LINE ARGUMENTS" for
detailed explanations.
Advice: Keep it simple. Assume that you don't need to use extra
command-line arguments unless you have special reason to think
otherwise. The above one-line batchfile will work for a vast
majority of systems, and making things more complex (copying the
dropfile to the game directory, changing directories, etc.) will
often introduce problems instead of avoiding them.
2. Add lines to your nightly maintenance file to run Ox maintenance on a
daily basis. Depending on your directory structure, the lines might
look like this:
C:
CD\DOOR\IRONOX
IRONOX /MAINT
If you have activated any bulletins in OxConfig, you will also want
to add a line like this to update the bulletins:
IRONOX /BULLETINS
You may choose to add IRONOX /BULLETINS to the batch file that runs
the game -- so that bulletins are updated whenever a player exits the
game -- but be aware that writing a complete set of bulletins,
including interBBS bulletins, may be somewhat slow (it takes about 5
seconds, for instance, on my 486-100).
That's all it takes! You're ready to add Iron Ox to your door menu and
get rolling!
Iron Ox for OS/2 for a Native OS/2 BBS:
Here are the key steps to installing Iron Ox for OS/2:
1. Copy the file DOORS2V5.DLL to a directory on the LIBPATH defined in
your CONFIG.SYS. On a typical system, the \OS2\DLL directory on your
boot drive works fine.
2. Create a batchfile or script to run the game. If you're running
Maximus or a similar BBS system, no batchfile is necessary: you can
add a script directly to your MENUS.CTL file. See below for
examples.
3. Add lines to your nightly maintenance file to run Ox maintenance on a
daily basis. Depending on your directory structure, the lines might
look like this:
C:
CD\DOOR\IRONOX
IRONOX /MAINT
If you have activated any bulletins in OxConfig, you will also want
to add a line like this to update the bulletins:
IRONOX /BULLETINS
You may choose to add IRONOX /BULLETINS to the batch file that runs
the game -- so that bulletins are updated whenever a player exits the
game -- but be aware that writing a complete set of bulletins,
including interBBS bulletins, may be somewhat slow (it takes about 5
seconds, for instance, on my 486-100).
Here's a script that will work fine on a single-node system using the
default DORINFO.MEC script that comes with Maximus:
Display_File C:\Max\Misc\Dorinfo Normal "Iron Ox/2"
NoDsp Xtern_Dos C:\Door\IronOx\IronOx.exe Normal "I"
Important question: Have you changed your DORINFO.MEC script to write
the name of the correct comm port to the dropfile instead of the number
of an open comm handle? (Many OS/2 sysops who run DOS doors have done
this.) If so, your script should look like this:
Display_File C:\Max\Misc\Dorinfo Normal "Iron Ox/2"
NoDsp Xtern_Dos C:\Door\IronOx\IronOx.exe_/PORT Normal "I"
Note: If you get errors accessing the port with this configuration,
make sure you have your serial driver configured to allow a comm port to
be shared across sessions (with SIO, you would need to use the "-"
parameter, described in the section on running from a VDM).
Are you running multinode? If so, copy MLTINODE.MEC (from this archive)
to your scripts directory, and use the following commands to run Iron
Ox/2:
Display_File Misc\MltiNode Normal "Iron Ox/2"
NoDsp Xtern_Dos \Door\IronOx\OX.cmd_%k Normal "I"
OX.CMD should look like this:
C:\DOOR\IRONOX\IRONOX.EXE /N:%1 C:\MAX\MISC\%1\
Note: For this setup to work, you will need to create node work
directories under \MAX\MISC\ for each node, like so:
C:\MAX\MISC\1\ (for node 1)
C:\MAX\MISC\2\ (for node 2), and so forth.
Another note: Depending on the configuration of your system, you may
wish to try using the /NICE parameter. See the section on command-line
arguments, below. You should only need to consider using the /NASTY
parameter if you run a multinode BBS and your users spend a lot of time
in ill-behaved DOS doors.
Installing Iron Ox for OS/2 for a DOS BBS in a VDM:
If you are running a DOS BBS under OS/2, you should be able to take
advantage of the enhanced features and performance of Iron Ox for OS/2.
I am now running my DOS BBS full-time under OS/2, so compatibility has
been a high priority for me from the beginning. Your mileague running
an OS/2 door under a DOS BBS may vary (some people report impressive
results, while others notice little difference), but I hope you'll be
glad to have the choice. :-)
To run Ox/2 from a DOS BBS, you must be using Ray Gwinn's SIO or
compatible drivers (COM.SYS/VCOM.SYS will not work). Recent versions of
SIO, working with OS/2 2.1x and above, will allow OS/2 and DOS sessions
to share a comm port. SIO must be loaded with the "-" parameter, which
allows port-sharing, and you must have the "Share comm port with OS/2
Sessions" option turned on in the DOS Sessions Settings for the session
in which you run your BBS.
To spawn OS/2 sessions from your DOS BBS, you will need OS2EXEC or a
similar utility. OS2EXEC creates OS/2 sessions that wait on commands
from DOS sessions; you run the door by telling OS2EXEC to execute
IRONOX.EXE.
Both OS2EXEC and SIO are available for FREQ and download from my BBS;
see the section on "SUPPORT," below.
So, with requirements and caveats stated, let's get to batch files and
configuration information. First of all, I have a startup .CMD file as
follows:
REM Start "Daemon" sessions for each of my three BBS nodes
START /FS OS2EXECD
START /FS OS2EXECD
START /FS OS2EXECD
REM End of startup .CMD
My Wildcat! batch file is very straightforward:
OS2EXEC C:\DOOR\IRONOX\IRONOX.EXE /PORT
If you are running a DORINFO system, you may need to use the /N
parameter. If Ox has trouble finding your dropfile, you may need to
specify it on the command line. See the general installation
instructions, above, and the information on command-line arguments,
below.
If you run a multinode system with high-speed lines and/or
non-timeslicing comm software (in other words, if there are other tasks
that eat up lots of CPU time when players will be in Iron Ox) you may
need to try the /NASTY parameter. See the section on command-line
parameters, below.
COMMAND-LINE ARGUMENTS
Iron Ox supports a number of command-line parameters. If the
documentation for any of these makes your eyes glaze over, your best bet
is to skip over to the next one. Chances are that if you don't
understand it, you also don't need it.
/ACCEPT This option tells Iron Ox not to mess with the
communications parameters currently set for your comm port
-- to open the port (or the FOSSIL driver, if appropriate)
as it stands. It is intended to help people whose systems
do not respond correctly when a door program attempts to
reset communications parameters. Advice: Assume you
*DON'T* need this option unless the game doesn't work
without it. (Note: This option has no effect under OS/2.)
/BULLETINS Updates any bulletin files you have activated in OxConfig.
/LOCAL This option tells Iron Ox to run in local mode, and not to
access the comm ports or look for a BBS dropfile. By
default, when running in local mode, Ox assumes it is
running on node 0. If you are running a multinode system
and want to run on a different node number, use the /N
option documented below.
/LOCK This option allows you to lock the BPS rate Iron Ox uses to
communicate with your modem to a speed other than the one
specified in your door information file. Example:
IRONOX /LOCK:19200
This option is only effective if you are using the internal
comm system (port-locking for FOSSIL drivers should be
controlled through FOSSIL driver setup). (Note: This
option has no effect under OS/2.)
/LRIP This option tells Iron Ox to run in graphics mode using the
same RIPScrip graphics a caller will see if he/she logs in
using a RIP terminal (like RIPTerm or QMPro). Notes:
(a) Local graphics are currently not supported in the OS/2
version of Iron Ox. (They are a possibility for an
upcoming version -- let me know if it's a feature you
want to see!)
(b) When you're not running in local mode (i.e., you aren't
using the /LOCAL parameter), the game will only run
with local graphics when the remote user (the caller)
also has RIP graphics. In other words, if the caller
only has ANSI, you see ANSI with or without /LRIP.
(c) If you run more than one node under a multitasker like
DESQview, you will probably want to ensure that only
one copy of Iron Ox is running in /LRIP mode at a time.
If multiple instances of the game try to access the
graphics display at once, screen corruption can result.
/MAINT This option runs daily maintenance, advancing the game to a
new turn. It MUST NOT be run when the game is in use on
another line, so IRONOX /MAINT is a good candidate for your
nightly maintenance event. Running IRONOX /MAINT *more*
than once a day (for a faster-moving game) works fine in
single-BBS mode; it's disabled in interBBS league mode to
prevent cheating.
/N: This option allows you to indicate the current node number
when the game is run on a multinode system. Example:
IRONOX /N:3
On most systems, the node number is included in the door
drop file and this option is not needed. The most common
systems where you *will* want to use this option are
DORINFO BBS packages like RemoteAccess.
/NASTY Systems running OS/2 BBS'es can be gentle and friendly
places where all software cooperates and shares the CPU;
others can be war zones where CPU-hungry DOS doors starve
the rest of the system. The /NASTY parameter warns Iron Ox
that it's running in one of those "war zones," and that it
needs to set its thread priorities very high to compete
with the "bullies."
You should probably not use this parameter unless you get
complaints about Iron Ox running very slowly and/or you
know you run lots of non-timeslicing DOS doors.
(Note: This option has no effect in the DOS version.)
/NICE The /NICE parameter is the natural counterpart of the
/NASTY parameter, documented above. Using the /NICE
parameter indicates to Iron Ox that it's running in a
friendly environment and that it can rely on CPU idle time
to do things like refresh the screen and dump output to the
comm driver.
On all-native systems or single-node systems with a light
CPU load, using /NICE should make for better performance
with substantially less CPU load. This option is almost
guaranteed, however, to provide miserable performance on
multinode systems running DOS BBS software and/or
non-timeslicing DOS doors.
Note: By default, Iron Ox is neither /NICE nor /NASTY: it
uses moderate thread priorities. Many sysops will need
neither the /NICE nor the /NASTY parameter; the parameters
are included to give sysops control over game performance.
(Note: This option has no effect in the DOS version.)
/NOFIFO Some Western Digital 16550 cards have a bug that causes
them to lock up when their FIFO buffers are used. This
flag tells Iron Ox to disable its use of FIFO buffers.
Note: If you've never heard of this FIFO bug before,
assume it *DOESN'T* apply to you and do not use this
option! If you had the problem, you'd know by now. <g>
(Note: This option has no effect under OS/2.)
/NOFOSSIL If you *have* a FOSSIL driver, but do *not* wish to use it,
this flag will tell the game to ignore the driver and use
internal comm instead. This option may be useful if you
are having problems with Iron Ox's FOSSIL support. Note:
If you do not have a FOSSIL, you do not need this option --
Iron Ox will automatically default to internal comm if it
does not find a FOSSIL. (Note: This option has no effect
under OS/2.)
/P, /I These options allow you to set the hexadecimal base address
and the IRQ number for a non-standard serial port. Example:
IRONOX /P:3F8 /I:4
indicates that the game should use base address 3F8h, and
IRQ4 for serial I/O. These arguments are *ONLY* needed if
you are using internal serial support; they are ignored if
you have a FOSSIL installed and have not used the /NOFOSSIL
argument. Note: The AT IRQ lines (9-15) are *NOT*
supported using these arguments. Support for the AT IRQ's
is only available through a FOSSIL driver.
(Note: This option has no effect under OS/2.)
/PLANETARY This option runs interBBS planetary maintenance: it
packs up all outbound information waiting to go to other
systems, processes any inbound packets from other systems,
and (if enough time has passed since the last planetary
maintenance) creates recon information packets from other
systems. Running IRONOX /PLANETARY has no effect on a game
that isn't part of an interBBS league.
This option may be run any number of times per day, and
works fine if run with a user on another node. It should
not be used in conjunction with /RESET or /MAINT.
/RESET This option tells Iron Ox to purge the current game and
brings up the "create new game" menu.
Note: Do not use this option while people are playing the
game on another node.
[pathname] By default, Iron Ox looks for a door drop file in the
current directory -- it expects to be run from the node
work directory, as described above. Also by default, it
will autodetect which dropfile to use by checking the
directory for the most current dropfile it supports (i.e.,
it does freshness-testing to avoid using stray dropfiles).
You can specify the path where Iron Ox should look for its
dropfile and (if necessary) the name of the dropfile to
use. Thus:
C:\DOOR\IRONOX\IRONOX.EXE C:\WC30\WCWORK\NODE1\
or, alternatively
C:\DOOR\IRONOX\IRONOX.EXE C:\QBBS\DORINFO3.DEF
Note: This command-line option is usually not necessary.
MULTINODE SETUP
Iron Ox was written and tested from the ground up to run multinode. In
general, multinode setup is *identical* to single-node setup: All nodes
use the same configuration file, and (for the most part) they can use
the same batch file, too. Because the program supports FOSSIL drivers
under DOS and uses the standard device driver model under OS/2, it can
handle issues like non-standard IRQ's *completely automatically* -- no
need to treat individual nodes specially on FOSSIL or OS/2 systems.
Multiple players can use this door at the same time; Iron Ox
handles all file locking internally. (Note: The file-locking system
supports node numbers up to about 1,000 -- if you need higher ones,
contact me and I'm sure we can work something out. <g>) The only
requirement for running the game multinode is that you must be running
DOS SHARE or some equivalent (like the built-in file-sharing in OS/2 or
the file-sharing facilities on LANs). If you're running multinode
*without* such a utility, now would be a good time to start.
To set up the door for multinode use, create batch files for each node
like those in the single-node instructions, above. The only times
different nodes will need *different* batch files are
(a) when the game is run across a LAN on which the drive letter for the
game directory is different for different nodes, and
(b) when you are running nodes with non-standard IRQ's under DOS and you
are *NOT* using a FOSSIL driver.
If you have a local node and you like to play the game with RIP
graphics, you may want to have a special batch file for the local node
to bring up the game with the /LRIP parameter.
(If you are running a multiline system where the node number is not
included in the door information file, like RemoteAccess with
DORINFO1.DEF, you will either need to use multiple batch files or use an
environment variable to specify the node number with the /N option. See
"COMMAND-LINE ARGUMENTS," above.)
Iron Ox includes a multinode chat/messaging system. By default,
Iron Ox looks for up to ten nodes on your system. If you have more
nodes than that (or if you have considerably fewer, and you want to save
your CPU a little work) you can visit the Multinode Menu in OxConfig and
adjust your Highest Node Number.
One more thing for DOS users: When you first enter OxConfig, you will
see a message about IRONOX.EXE being flagged read-only. This is a
workaround to cope with a bug in Borland's overlay manager, and should
have no effect on day-to-day use of the game. If you should ever need
to reverse the process (to upgrade or remove IRONOX.EXE), type the
command ATTRIB IRONOX.EXE -R from the DOS prompt. This issue does not
come up under OS/2.
That's all it takes! Iron Ox uses lock files to control simultaneous
use of files, so resources may remain locked if the system crashes while
someone is in the door. However, each node clears all of its locks
every time it enters or exits the door normally, so "lingering locks"
will be cleared automatically. If you ever need to clear the lockfiles
manually, you can do so by typing "DEL C:\DOOR\IRONOX\*.L*" (though this
will delete your Iron Ox logfiles, too).
COMMON PROBLEMS
1. My BBS makes one of the dropfiles the door supports, but the game
keeps telling me it can't find a dropfile!
This game assumes that you are running it from the directory where
your BBS dropfile is located. If you aren't, include the directory
where your dropfile is located on the command line, thus:
C:\DOOR\IRONOX\IRONOX.EXE C:\WC30\WCWORK\NODE1\
If you're running a DORINFO system, specifying the node number on the
command line might also be useful:
C:\DOOR\IRONOX\IRONOX.EXE /N:3 C:\QBBS\
2. The game works fine locally, but doesn't work over a modem!
If you're running under DOS and you're having trouble getting serial
support to work, one good solution is to try a FOSSIL driver. FOSSIL
drivers are an excellent choice for high-performance communications,
and can (if you wish) be loaded and unloaded from the batch file that
executes Iron Ox. If you do not have a FOSSIL driver, they are
available from my system (listed under "Support," below), and many
other places as well.
If you don't wish to use a FOSSIL, the /ACCEPT, /LOCK, /P and /I
options explained in the section on command-line arguments may help
with the problem. If not, or if you're already *using* a FOSSIL and
are still having problems, feel free to contact me for further
assistance.
3. I'm running Iron Ox for OS/2, and I keep getting a "critical error
setting DCB" or something like that whenever the game tries to run
across a modem!
Usually, this error means that Iron Ox is trying to open the wrong
comm port or a comm port that doesn't exist. There are two common
causes for this:
(a) you're using the /PORT parameter when you shouldn't be or not
using it when you should be, or
(b) the door is finding the wrong dropfile.
If you're running a DOS BBS in a VDM, you need to use the /PORT
parameter. If you're running a native OS/2 BBS, you may or may not
need it: try removing it/adding it. If fixing your /PORT setting
doesn't address the problem, try specifying the location/name of the
door dropfile on the command line.
4. I'm running the DOS version of the game. The game runs fine
single-node, but if two people try to go in at once, I get a sharing
violation!
As I say in the section on multinode setup, the Borland C overlay
manager has a bug that causes sharing violations when you try to run
an overlaid program multinode. The work-around for this problem is
to flag your IRONOX.EXE file read-only; you can do this by running
OxConfig, or by using ATTRIB IRONOX.EXE +R.
5. The game is getting confused about what node it's running on!
Iron Ox is designed to figure out the node ID on which it's running
from the BBS drop file. On some systems, however, determining the
node ID from the drop file is not possible. See the documentation
for the "/N" command-line parameter, above. If you're using /N and
Iron Ox is *still* getting confused, chances are that Ox is
finding a stray dropfile. Try specifying the name and location of
the dropfile on the command-line (as described above).
6. I run under DOS, and I'm getting some weird message about SHARE not
being loaded!
If you're running Iron Ox multinode, you need to have SHARE (or an
equivalent utility) loaded. Consult your operating system manual for
information on using SHARE.
If you're not running multinode, you shouldn't need to have SHARE
loaded on your system. Go into OxConfig, visit the Multinode Options
menu (under "General Options") and set your "Highest Node Number" to
zero. (Actually, you probably won't even get as far as the main menu
-- OxConfig will detect the problem with SHARE and prompt you to turn
off multinode support as soon as you run the program.)
7. The game runs fine multinode, but my game files are getting corrupted
or I am having sharing violations when nightly maintenance runs!
As mentioned above in the section on "COMMAND-LINE ARGUMENTS,"
nightly maintenance (IRONOX /MAINT) *MUST NOT* be run while users are
in the door. (Future versions may support running /MAINT multinode,
but even then it won't be recommended for performance reasons.)
IRONOX /MAINT should be run as part of your nightly maintenance when
no users are online.
Note: This restriction only applies to nightly maintenance, run with
IRONOX /MAINT. IRONOX /PLANETARY, IRONOX /BULLETINS, and other game
maintenance routines work fine run multinode.
8. When I run the game, I'm getting a weird message like:
Assertion failed, iRec < OvrFileHeader.iOvrRecords[Overlay]
This error usually means that your IRONOX.EXE and your TEXT.OVR file
(two files that come in the standard Iron Ox distribution archive)
are different versions. One common reason this happens is that you
have recently upgraded to a new version while IRONOX.EXE was flagged
read-only -- TEXT.OVR was successfully upgraded to the new version,
but your unarchive utility failed to update IRONOX.EXE.
If this situation could apply to you, here's the solution: Un-flag
IRONOX.EXE using ATTRIB IRONOX.EXE -R, repeat the upgrade procedure,
and then enter OxConfig to reflag the game read-only. If this
doesn't work for you, please contact me for more help.
CONFIGURING IRON OX
The easiest way to configure Iron Ox is to use the OxConfig utility
included with Ox. This utility allows you to edit values in your
IRONOX.CFG file, and includes range-checking and online help. If you
prefer to edit IRONOX.CFG (an ASCII file) manually, see IRONOX.SAM for
information on the options in the file.
Note: If you are running an interBBS league and have relatively
complicated routing (more than one hub, numerous routing exceptions),
you may need to edit the routing section of your IRONOX.CFG manually.
Information about IBBS routing appears in IRONOX.SAM and INTERBBS.DOC.
CUSTOMIZING
The following information is for "power users" only. <g> None of the
customization described in this section is strictly necessary.
Iron Ox reads and uses two ASCII text files in your IRONOX directory
other than IRONOX.CFG:
1. CONTESTS.TXT -- This file is a straightforward list of the titles
used for the Colony Cultural Competition. By default, it includes
the following entries:
ASCII Art
Annoying Pun
Political Tirade
O.J. Simpson Joke
Interesting Trivia
So long as you leave at least one choice on the list, you may add or
delete entries as you like (Ox chooses randomly from the entries on
the list whenever it creates the game). The maximum length for
contest names is 30 characters.
2. EXCLUDES.TXT -- This file is not included in your Iron Ox archive --
if you want it, you need to create it.
In the registered version of Ox, the game can award time prizes to
the player with the highest daily, weekly, and monthly score.
Obviously, users with extremely large daily time limits (the sysop
and any co-sysops) have no need for time prizes. By excluding such
people from contention for time prizes, you can stimulate more
interest in the prizes.
EXCLUDES.TXT can include up to ten names (one per line, ASCII text)
of people to be excluded from winning time prizes.
EXTERNAL PROTOCOLS
Iron Ox supports automatic in-game downloading of RIP icon files. To
activate this option, visit OxConfig's General Settings|General Config
menu and entered a valid path and filename for an external protocol.
One important caveat about Iron Ox's use of external protocols. The
MS-DOS version of Iron Ox assumes that any protocol will use a
DSZ-style command line:
dsz port 1 sz @files.lst
The OS/2 version assumes that any protocol will use a CEXYZ/2-style
command line:
cexyz2 /P12 /B38400 /Sz @files.lst
Note that the CEXYZ/2 command line includes a comm handle, not the name
of a comm port to open.
Iron Ox has been tested with DSZ and CEXYZ/2, and those protocols are
recommended. If you are using a protocol other than DSZ/CEXYZ/2 that
uses a similar command line, you may be able to run that protocol by
entering a batch file name in OxConfig and using that batch file to
"translate" the command line arguments.
MAINTAINING IRON OX
In the installation instructions (above), you read about how to use
IRONOX /MAINT in your nightly maintenance batch file to advance the game
to new turns. You also will need to run IRONOX /RESET to create new
game files when the game comes to an end (by default, this will only
happen every few months).
In general, that's all the maintenance you'll need to do! If you have a
problem user and you need to delete him/her or edit an alias, running
IRONOX /LOCAL /EDIT calls up a very minimal editor that includes this
function. As you may know, Iron Ox 1.x and 2.x included a much more
complete game editor. However, because Iron Ox 3.x is intended to run
interBBS, and because accusations of cheating are so common in interBBS
leagues, a comprehensive editor is not included in this version, and the
data files were encrypted to discourage direct modification.
ERRORLEVELS
In case your BBS software reads and uses errorlevels on door exit, here
are the errorlevels Iron Ox returns:
0 - Critical error has occurred!
1 - The user has dropped carrier.
2 - The sysop has terminated the call; user off-line.
3 - User time has expired; still on-line.
4 - Keyboard inactivity timeout; user off-line.
10 - Normal exit; user on-line.
255 - Program integrity problem; please check log and contact me!
LICENSE/REGISTRATION INFORMATION
This program is copyrighted shareware. You are licensed to try this
program for up to 30 days. After 30 days, if you elect to continue
using Iron Ox, you must register.
The game costs only US$20. If you wish to register using a credit card,
you can use your modem to call 619-462-8406 or 619-462-7146 to obtain
your registration key instantly using online registration. (Note: To
do this, you have to go through my normal questionnaire/login process.
If you're concerned about long distance expenses -- e.g., if you're
calling internationally -- see INTLREG.DOC for instructions on how to
work around that!) If you prefer to use conventional mail and a check
or money order, see REGISTER.FRM for information on shipping and
delivery options.
Iron Ox is not "crippleware": the unregistered version is a complete
and enjoyable game. However, the registered version of Ox does include
the following enhanced features:
1. MORE LAND IMPROVEMENTS: In the registered version of the game, your
players are allowed to build three powerful improvements (the luxite
refinery, ore refinery, and power plant) that noticeably improve
production of luxite, ore, and energy. Because these improvements
are "unique" -- each colony may only have one of them! -- the battle
over who controls them can add extra excitement to the game.
2. EXTRA RACES: In the registered version of the game, three extra,
specialized races are available to players: the Photovore, a
sunlight-eating alien who specializes in plants and energy-making;
the Rubblemuncher, an amazing ore-miner who's allergic to luxite; and
the Metamorph, a creature who can actually *change shape* and assume
the abilities of different races during the course of the game.
3. EXPERT AND NIGHTMARE MODES: In the evaluation version, you may only
choose beginner and intermediate skill levels for the game. In the
registered version, you can give your players an extra challenge by
selecting expert or nightmare mode!
4. TIME PRIZES: If you own the registered version and use BBS software
that "reads back messages" from doors, you can set (totally optional)
daily, weekly, and/or monthly time prizes for the leaders in the
standings! This feature works on Wildcat! (3.x USERINFO.DAT and 4.x
SYSINFO.DAT), SpitFire (SFDOORS.DAT), and many other systems.
5. TROJAN OXEN: Trojan Oxen are a valuable defense against sabotage:
They look like ordinary oxen, but *fight back* if attacked. Very
helpful in cutthroat and interBBS games.
Please see REGISTER.FRM to find out how to register your copy of Iron
Ox. Iron Ox is the product of countless hours of work. I need your
help to continue developing enhancements and new features.
ADDITIONAL LICENSE INFO
You are allowed (and encouraged) to distribute unmodified copies of Iron
Ox so long as you distribute the complete archive with all files intact.
You may include unmodified, complete archive versions of the shareware
edition of Iron Ox in software collections (e.g., CD-ROMs) so long as
the documentation for the collection clearly indicates that it contains
shareware products and that the purchase of the collection does not
constitute a license for the use of said products.
Registration of this product entitles you to a unique registration code
keyed to your name and the name of your BBS. This key will allow you
and your system's users to access the registered-only features of the
program, and will deactivate all messages to the effect that the program
is an "Unregistered Evaluation Copy." Your registration is good for all
future releases of Iron Ox for DOS and OS/2: If I should ever need to
change the key system, you as a registered user will be entitled to
receive a working new key on request via U.S. Mail or electronic mail.
Registrations are non-transferable without my direct permission.
FUTURE PLANS
Iron Ox has an exciting future. You can find out the latest about Iron
Ox development and new features by visiting the Iron Ox Home Page on the
World Wide Web (See "SUPPORT," below). Here are a few of the features I
am considering for upcoming versions of Iron Ox:
1. Four more drone classes, including a drone capable of attacking
forts, a hunter/killer drone to track specific players, a "carrier"
drone to transport cybermutts, and a "ground-mauler" drone to destroy
land. If you have other ideas, I'd like to hear about them!
2. A completely reworked message system including support for
"multimail," carbon copies, quoting on reply, messages to all, and
global (interBBS) announcements.
3. Support for remote reset, remote configuration reports, and remote
configuration changes in interBBS leagues.
4. "Multi-BBS" attacks where several BBS'es can pool resources to attack
more powerful systems.
Many of the most important features in Iron Ox originated in user
suggestions. If you have ideas you'd like to see in future versions,
please let me know!
SUPPORT
I appreciate your feedback and ideas. If you have problems getting Iron
Ox to run, please feel free to contact me.
I am moderator of the Fidonet IRONOX echo, which is distributed via the
Zone 1 echomail backbone. This echo is an excellent place to get help
with the game, discuss improvements for future versions, and get access
to game tips for your players! Please note: I attempt to read all of
my personal mail regularly. However, due to the large volume of mail I
receive, I do sometimes get behind. If you need a reply from me
quickly, please feel free to e-mail or crashmail me, but also consider
posting a public message in the IRONOX echo. Many knowledgeable people
read that area, and may be able to provide faster answers than I can.
I also monitor the Fidonet DOORWARE, DOORGAMES and ON_LINE_GAMES
conferences for *personal* mail (please address it to "JOEL DOWNER" if
you want a reply from me!). I also monitor the General Mail and Ox
Local Support conferences on my BBS for personal mail.
I can be reached via netmail at Fidonet address 1:202/704. I am also
reachable via the Internet as joel@dreamcty.cts.com.
The support BBS for Iron Ox, and for all software by Joel Downer, is The
Dreaming City. The Dreaming City has two lines:
Node 1: USR Courier "V.Everything" 28.8 (619) 462-8406
Node 2: ZyXEL 16.8 v.32bis (619) 462-7146
The latest version of Iron Ox for DOS and for OS/2 is available for
download on my BBS, for FREQ (magic names: IRONOX for the DOS version,
OX2 for the OS/2 version) from either of my Fido nodes, and for
anonymous ftp from ftp.cts.com, in the /pub/joeld directory. Iron Ox
also has a home page on the World Wide Web, at
http://www.free.cts.com/crash/j/joeld/ox.html
The WWW page is a new experiment, and I welcome your feedback. :-) It
includes information on recent development, future plans, and more!
IRON OX DISTRIBUTION SITES
The following bulletin board systems are official distribution sites for
Iron Ox and any necessary companion programs. Note: This information
was compiled in May 1996; some of these telephone numbers will change
over time. If you find that the numbers listed for systems in your area
are no longer accurate, you may be able to find up-to-date information
in a current FidoNet nodelist.
BBS System Fido Addr Telephone Modem Where
The Dreaming City 1:202/704 619-462-8406 28.8+ La Mesa, CA
TDC 2 1:202/705 619-462-7146 V.32bis La Mesa, CA
Blackbeard's BBS 1:19/19 318-468-3385 V.34+ Ville Platte, LA
Common Sense 1:215/705 510-713-7336 V.34+ Newark, CA
Genesis 1:393/6 817-241-2314 V.FC Copper Canyon, TX
The Harry Beast 1:343/102 206-859-6157 V.32bis Kent, WA
Hi-Flite BBS 1:137/217 941-753-4458 V.34 Bradenton, FL
Hole in the Wall 1:104/651 303-841-5515 V.34+ Parker, CO
Holston River Vlly 1:3615/44 615-932-1490 V.34+ Knoxville, TN
ISMWare Support 1:134/31 403-686-0449 V.FC Calgary, AB
Little America BBS 1:271/291 804-564-9014 V.34 Williamsburg, VA
Mayberry BBS 1:3663/302 910-789-8183 V.FC Mt. Airy, NC
Phantom BBS 2:259/26 +44-1224-709833 V.34 Aberdeen, Scotland
Ruby's Joint 1:112/129 904-777-6799 V.FC Jacksonville, FL
S.P.I. BBS 2:259/61 +44-1506-857709 V.FC Broxburn, Scotland
Test Pattern BBS 1:259/524 905-890-2531 V.34+ Ontario, Canada
The Toyland BBS 1:123/117 901-835-4016 V.34 Drummonds, TN
OTHER SOFTWARE BY JOEL W. DOWNER
Fiction Factory Fiction Factory is a "never-ending story" door aimed
at the modern BBS. It includes full RIP support
(including optional local RIP); a full-screen,
scrolling windowed text editor and file viewer;
context-sensitive, popup help; real-time multinode
support; up to 255 stories at a time; password-
protected stories; and more!
File: FFCV100.ZIP (DOS Version), Magic Name: FICTFACT
File: FFC2V100.ZIP (OS/2 Version), Magic Name: FF2
Doors/2 Doors/2 is a complete toolkit for developing C/C++
doors for OS/2. It's based on the OpenDoors API, and
allows you to port a DOS door written for OpenDoors
with little more than a recompile! Features include
32-bit multithreaded performance, full support for a
wide range of BBS'es/dropfiles, built-in multinode
messaging and chat, full-screen editing capabilities,
and more!
File: DRS2V500.ZIP, Magic Name: DOORS2
DISCLAIMER
I make no warranty of any kind regarding the usefulness, reliability,
merchantability, or fitness of this software and documentation for any
purpose whatsoever. While I have tested this program thoroughly, I
cannot and will not make any promises that the program will run well or
safely on your hardware or with your particular software configuration.
This software is guaranteed only to take up disk space, and I make no
absolute guarantee that it will do a reliable job of that.
Your use of Iron Ox and/or any companion material constitutes your
acceptance of these terms.
ACKNOWLEDGEMENTS
To paraphrase J.R.R. Tolkien, Iron Ox is a tale that has grown in the
telling. When I wrote the first version of Iron Ox in the Fall of 1993,
I don't think I could have imagined that it would some day have features
like local graphics, interBBS support, and real-time multinode
interaction.
Credit for the continued growth of the door belongs to many people who
have provided inspiration, encouragement, or concrete help along the
way. Please see the HISTORY.TXT file for a specific list of heroes who
have made a big difference in the creation of this version.
Iron Ox's support for RIP uses a C RIP library that is (loosely) based
on Tom Morgan's Pascal RIPLink library. Thanks to Tom, and to the
maintainers of DDPlus -- Steve Lorenz and Bob Dalton -- for making
RIPLink and the DDPlus tookit, in which RIPLink is now contained,
available in source form to door authors everywhere.
The DOS version of this door also uses the OpenDoors C development
system by Brian Pirie. That system has saved me countless worries about
the details of talking to the modem, reading dropfiles, etc., and I'd
highly recommend it to any C programmer writing a door. The OS/2
version uses my own Doors/2 port of OpenDoors; see "OTHER SOFTWARE BY
JOEL W. DOWNER" for more information.
Finally, thanks to Evvie Vincow for near-lethal persistence.